Fixes #10269

Include the exception message in <failure>/<error> bodies

Today the JUnit report writes only Exception.StackTrace into the element body, keeping the message in the message attribute. Consumers that render the body rather than the attribute — GitLab CI and CircleCI most notably — therefore show a bare stack trace with no indication of why the test failed. This is especially damaging for fluent assertion libraries, where the stack trace is mostly framework frames while the assertion message carries the actual diagnosis.

This is a fidelity gap, not a stylistic choice. Canonical JUnit bodies come from Java's Throwable.printStackTrace(), whose first line is com.example.AssertionError: expected:<1> but was:<2> — the message is inherently part of the body. .NET's Exception.StackTrace omits that header (only ToString() includes it), which is exactly why our output looked message-less next to a genuine Surefire report. GitLab isn't being quirky; it's reading the body assuming Java semantics.

The body now mirrors printStackTrace():

<failure message="Expected the operation not to throw, but it threw ..."
         type="Xunit.Sdk.XunitException">
Xunit.Sdk.XunitException: Expected the operation not to throw, but it threw ...
   at FluentAssertions.Execution.LateBoundTestFramework.Throw(String message)
   ...
</failure>

Each part degrades gracefully: a missing exception type drops the header prefix, a missing message drops the : separator, and a missing stack trace yields a header-only body.

Why change the default instead of adding an option

The issue proposed a --report-junit-failure-body-format option. We went with changing the behavior outright:

• Microsoft.Testing.Extensions.JUnitReport has not shipped a stable version (only 1.0.0-alpha.* on NuGet), so there is no back-compat cost to fixing the default now. This is the one moment where it's free.
• A CLI option is a permanent contract, and it would only let users opt into less diagnostic information. Adding one later is non-breaking; removing one is not.
• Both schemas allow it: neither the Ant/windyroad JUnit.xsd nor Surefire's surefire-test-report.xsd constrains the body — it's free-form text (the Ant schema's "e.g., a stack trace" is illustrative, not normative).

The message and type attributes are unchanged, so consumers reading them directly are unaffected. The resulting duplication between attribute and body is exactly what every Maven/Surefire report already exhibits, so consumers rendering both have long handled it.

Unlike spekt's FailureBodyFormat=Verbose, we deliberately do not fold standard output into the failure body — it's already emitted as <system-out> per test case, and duplicating it would bloat reports for noisier suites.

Always emit the type attribute

The Ant/windyroad JUnit.xsd marks type as use="required" on <failure>/<error> (Surefire relaxes it to optional). MTP only supplies an exception type when the state property carried an actual Exception — frameworks that report a failure through Explanation alone leave it null, so the attribute was previously omitted entirely in that case.

type is now always written, falling back to the element name (failure / error) when no exception type is available. That keeps the document valid under the stricter schema without inventing a bogus exception type name.

Testing

• New unit tests (JUnitReportFailureBodyTests) covering every combination of present/absent exception type, message and stack trace, plus the type fallback for both <failure> and <error>, asserted against real generated XML.
• Updated acceptance snapshot in Microsoft.Testing.Platform.Acceptance.IntegrationTests/JUnitReportTests.cs — the <failure>/<error> elements are no longer self-closing.
• Verified locally: 795 unit tests pass, 21 MTP JUnit acceptance tests pass across all TFMs, and the MSTest JUnit retry acceptance test (which produces real stack traces) passes.

Docs

docs/RFCs/016-JUnit-Report.md updated with a "Failure and error body format" section, a "The type attribute" section, and the revised outcome-mapping table.